The invention relates to call connection set-up and, more particularly, to playing announcements to a call party in a telephone exchange during connection set-up.
Telecommunication network exchanges are responsible for call set-up control and switching of a connection between subscribers. In the most simple case, the exchange receives a call set-up request from the calling party or from another exchange and switches the connection further to the called party or to the next exchange. In practice, the operation of the telephone exchange during call set-up is a complicated process which includes a number of successive sub-processes. These may include subscriber-specifically triggered special services, number analyses, call forwarding, special tariffs, and so on. Intelligence required for these operations may reside in the exchange or, now more commonly, in an intelligent network (IN) that is connected to a basic network (such as a public switched telephone network PSTN).
The intelligent network enables faster, easier and more flexible implementation and control of services. This takes place by displacing at least part of service control away from the exchange to a separate functional unit in the intelligent network. Consequently, the services can be made independent of the operation of the basic network, and the structure of the basic network and its software need not be changed upon change or addition of services. An example of such an intelligent network is described in recommendations of the International Telecommunications Union (ITU-T) Q-1200 series. The equipment or network element carrying out the tasks determined by the intelligent network service control function/s (SCF) is called a service control point (SCP). Within the scope of the present application, SCF and SCP are equal, and will hereinafter be called SCP. The SCP gives call set-up instructions to the exchange, or the exchange may inquire call set-up instructions from the SCP. Exchanges responsible for an intelligent network interface are called service switching points (SSP). They comprise at least a service switching function (SSF) and a call control function (CCF). The call control function CCF is not a function associated with the intelligent network, but it is a standard existing function in exchanges and comprises high-level call handling functions of an exchange, such as establishing and releasing transmission connections. The service switching function SSF is an interface between the call control function CCF and the service control point SCP. Within the scope of the present application, the service switching point SSP and the functional entity formed of the CCF and the SSF are equal, and will hereinafter be called SSP.
In conventional call set-up which takes place without the help of the intelligent network, telephone exchanges make independently all decisions associated with call routing. In the intelligent network, decisions associated with the routing are also made by the SCP.
Different stages of call set-up may include intermediate announcements which notify a party to the call, typically the calling subscriber, of progression of the call or give other call-related information, such as tariff information. In the intelligent network application, for example, upon detecting a specific stage or event of the call, the SCP may request the exchange to play an announcement to a call party, typically the calling subscriber. Nowadays, the exchange plays the announcement immediately upon being notified thereof, such as immediately after the request given by the SCP.
The handling of the prior art announcement presents such problems as:
1. Unnecessary charging: In chargeable announcements, charging starts immediately and cannot be interrupted in prior art exchanges. If the announcement is delivered at an early stage of call set-up and the call set-up fails, then the subscriber will possibly have to pay for an xe2x80x9cunnecessaryxe2x80x9d conversation time which starts from the first moment of playing the announcement and ends in release which is carried out because of a call set-up problem (a release announcement may also become chargeable).
2. Unnecessary announcements: an announcement (associated with call forwarding, for example) is delivered at some stage of call set-up, although the call set-up may later fail. Consequently, the announcement is possibly unnecessary and unnecessarily reserves exchange recourses (the announcement delivered first delays the detection of the reason for release; the resources allocated to the call are possibly unnecessarily reserved) and announcement resources (if the announcement is unnecessary).
3. Collecting additional dialling is hindered: The exchange has to transmit an AddressCompleteMessage (ACM) towards the calling party in connection with an announcement. The message has at least two meanings: firstly, it indicates that dialling is completed and secondly, it provides the originating exchange (the direction towards subscriber A) with a state in which voices/announcements can be connected to the call. Because of the first meaning, additional dialling is no longer accepted to the dialled number (the dialling is send_complete). If the announcement is played at a very early stage of the call and if the incoming signalling used (either between the subscriber and the exchange or exchanges) is such that the dialling may be provided by more than one message, new additional dialling messages can no longer be received and the call has to be released, because additional digits required for the analysis of the dialled number cannot be requested/obtained. (Additional dialling may be requested from the network by R2, whereas ISUP, for example, provides the additional dialling directly by subsequent address messages (SAM)).
4. Impossibility of prioritizing or optimizing different announcements which are delivered at different call set-up stages: The basic operation is to deliver an announcement immediately after information is received which indicates that such an announcement has to be delivered in a service. Later in call set-up an announcement from another service can be received to be delivered. On some occasions, however, it would be sensible to deliver nothing but the second announcement. However, this is not possible, because the first announcement has already been delivered.
5. Centralized management of announcements caused by different features: An announcement determined by a feature cannot be blocked by another feature (which is activated later).
6. Call set-up delay: Announcements delivered at a call set-up stage cause call set-up delay, because the announcement is delivered immediately as a whole. If the announcement is shifted to a normal wait state of the ACM, for example, the stages of call set-up which are also normally executed rapidly can then be executed without delay.
7. No opportunity to generically control an announcement that has been delayed (and is also conditional, if necessary) at a call set-up stage: For example, an announcement which is delivered when an event takes place (in connection with call waiting, for example) at a speech stage could be set in advance at the call set-up stage.
An object of the invention is thus to provide a method and equipment implementing the method so as to solve the above problems.
The objects of the invention are achieved by a method according to claim 1.
The invention also relates to a telecommunication network exchange according to claim 11.
The invention is based on the idea of totally separating the detection of the need for an announcement from playing the announcement. In the invention, the need for the announcement is detected in a conventional manner at a given stage of call set-up. In the invention, however, the exchange does not play the announcement immediately, but delays playing it up to a later stage of call set-up or in a later event, if necessary. The announcement may be played, for example, not until the collecting of additional dialling is definitely terminated, the call is confirmed to be successful, the exchange has to transmit an ACM message in backward direction in any case, the announcement is confirmed to be necessary/correct, and so on. The announcement is delayed to be played at a stage of call set-up or in the event which depends on the implementation of the respective exchange and on problems which are desired to be avoided by delaying the announcement. It should be noted that the exchange of the invention may play without delay some of the announcements in a conventional manner immediately after the detection of the need, in case this does not cause problems of the above type.
According to a preferred embodiment of the invention, when the need for an announcement is detected, at least data (such as announcement index or name) necessary for the selection of the correct announcement is stored from the announcement. In addition, the call set-up stage is preferably stored at which the announcement is desired to be delivered. This data may also be fixedly defined; certain announcements are played at a given stage, for instance. Other data to be stored may involve announcement category/type and priority or the rules which determine the way of handling other announcements (prohibit others, others can overwrite this, and so on) which are associated with the set-up of the same call and obtained for different reasons. If announcements are obtained more than once in a call, the data of each announcement is preferably separately stored in an announcement-specific data item in a data structure reserved for this purpose.
The data of the announcements may be stored in a queue-like or a stack-like data structure. The structure depends on what is done during the storage of the announcements. If the announcements are arranged chronologically according to set-up stage and priority, it is perhaps sensible to use a stack in which an announcement with the highest priority and associated with the next nearest call set-up stage is always uppermost in the stack. On the other hand, if the order is not defined in association with the announcement, it is possible to use a queue, for example, in which the announcements are inputted in succession according to the order of detection.
The data structure which includes the announcement data has to be examined at all call the set-up stages which can be defined for the announcements. When such a stage is encountered, it is necessary to start the handling of the data structure items associated with the call set-up in question. The handling procedure depends on whether the order of the data structure has been defined in connection with the storage. Furthermore, it should be noted that more than one announcement may be associated with the same stage; when a set-up stage is encountered, all the necessary announcements have to be delivered.
The data structure defining the announcement data may also be handled at call phases others than those at which announcements can be delivered. For example, a service associated with the call may delete from the data structure all announcements which fulfil certain conditions. Furthermore, a service may control the operation of a storage stage of the announcement to, for example, not to store the announcements in the data structure although the need for an announcement is detected, or to only accept announcements which fulfil certain conditions.
In the following, it will be briefly described how the invention solves or alleviates the above problems associated with prior art handling of announcements.
1. A chargeable announcement can be controlled to start at the latest possible stage of call set-up. An xe2x80x9cunnecessaryxe2x80x9d chargeable time can then be minimized. If the chargeable announcement is found unnecessary at a playing stage which is set according to the invention, then there is no need at all to start the charging.
2. The number of unnecessary announcements is minimized by delaying the announcements up to the call set-up stage at which it can be ensured as far as possible that call set-up is successful. Such a sufficiently late stage occurs when a message ACM is awaited from the direction of subscriber B or even a later after an answer message (ANM) is received from the direction of subscriber B, for example.
3. Announcements can be delayed at a stage at which analyses of how much dialling is required have been carried out. Such a stage may be a stage at which an ACM or an answer is awaited from forward direction, for example.
4. Since the announcements are delivered not until the required call set-up stage has been reached or the event has been encountered, all the announcements can be optimized and prioritized on the basis of data defined for all announcements and on the basis of call set-up events. In other words, as long as the announcement has not been delivered, it can be blocked, accepted, or totally deleted from the data structure. Priorization rules may comprise xe2x80x9conly play the announcement with the highest priorityxe2x80x9d, xe2x80x9cplay the latest announcement onlyxe2x80x9d, xe2x80x9cdeliver the first announcement onlyxe2x80x9d, xe2x80x9cannouncement X and announcement Y are mutually exclusivexe2x80x9d, and so on.
5. Most problems are solved by centralized management of different types of data (announcement data structure and/or other features) and announcements determined in the same call on the basis of call events.
6. Set-up rate can be optimized by delaying the announcement to be played at a stage at which it does not delay the normal set-up until it is also otherwise necessary to wait for a message coming from the network, for example.
7. The mechanism of the invention allows the storing in advance of conditional (the condition being an event in the call, for example) announcements which are to be delivered later on in the call.